Every major MES vendor now has an AI copilot in market or on the roadmap, and the pitch is nearly identical across all of them: ask a question in plain language, get an answer grounded in your plant’s data. Downtime causes, changeover recommendations, root-cause hints on a quality excursion. The demos are genuinely impressive. Then the pilot goes live on an actual line, and the agent gives an answer that’s fluent, confident, and wrong — not because the model is bad, but because nobody told it about the fixture change that happened on shift two, or the fact that spec revision C superseded revision B eight months ago and the historian tag still says “B” in a comment field nobody reads.
This is the part of the AI rollout that vendors gloss over and that practitioners are now hitting head-on. The model is not the bottleneck. The context is.
Why the historian isn’t enough
A Unified Namespace built on MQTT Sparkplug B or an OPC UA information model gives you clean, structured, real-time process data — temperatures, cycle times, machine states, quality tags. That’s necessary but nowhere near sufficient for an AI agent to reason like a competent operator or process engineer. The UNS tells you what happened. It almost never tells you why it matters, what’s normal, or what to do about it.
That interpretive layer — the work instruction that explains torque sequence on a specific fixture, the quality spec that defines an acceptable defect at a specific station, the maintenance tech’s note about a sensor that drifts in humid weather, the tribal knowledge that lives in one operator’s head — sits outside the historian entirely. It’s in PDFs, laminated cards taped to a machine, SharePoint folders, paper logbooks, and people’s memories. None of it is in a format an LLM can retrieve reliably, and most of it was never written with retrieval in mind.
An agent that only has UNS access will answer every question with statistically plausible, generically correct, plant-specific-wrong output. It’ll tell you the textbook cause of a defect pattern instead of the one that’s actually been plaguing your line 3 stamping press since the last die rebuild.
The context layer: what it actually is
Think of the context layer as a parallel structure to your UNS — not a replacement, a companion. Where the UNS organizes real-time and historical process data (typically following an ISA-95-style equipment hierarchy), the context layer organizes the plant’s explanatory knowledge and makes it retrievable by an agent at query time. In practice this means three things happening together:
- Structured documents — work instructions, quality specs, SOPs, and maintenance procedures converted from static PDFs and paper into versioned, tagged, machine-readable form, linked to the specific asset, line, or SKU they apply to.
- Embeddings and a retrieval index — that document set chunked and vectorized so a retrieval-augmented generation (RAG) pipeline can pull the right passage, not just keyword-match on a filename.
- Retrieval routing — logic that decides, for a given question, whether the agent needs UNS/historian data, a document lookup, both, or a human escalation — and that stitches the two data types into one coherent context window before the model ever generates an answer.
None of this is exotic technology. RAG architectures are well understood at this point. What’s hard, and what plants consistently underestimate, is the unglamorous work of getting the source material into a state where retrieval is even possible.
What to digitize first — a triage framework
You will not digitize the entire plant’s documentation before your first agent deployment, and you shouldn’t try. Prioritize by where wrong answers do the most damage and where tribal knowledge is thinnest:
- Quality specs tied to active defect modes. If an agent is going to advise on a quality excursion, it needs the current spec revision, tolerance bands, and inspection criteria for the parts actually running — not a generic version.
- Work instructions for your highest-changeover or highest-variability lines. Stable, rarely-changed processes are lower risk if the agent guesses wrong. High-mix lines are where context gaps bite hardest.
- Maintenance logs and technician notes for chronic failure modes. The repeat offenders — the sensor that drifts, the bearing that always goes at the same interval — are exactly the tribal knowledge an agent should absorb, and exactly the knowledge that walks out the door with a retiring tech.
- Safety and lockout/tagout procedures, digitized and flagged for mandatory human review regardless of how confident the agent sounds. This is not optional and not a place to save time.
- Changeover and setup sheets, since these are frequently updated, frequently ignored in favor of memory, and a common source of the “technically correct, plant-specific wrong” answer.
Notice what’s missing from that list: general process theory, vendor equipment manuals for stable equipment, and anything already well covered by existing SCADA alarms. Those can wait.
Validating agent answers before you trust them on the floor
The instinct is to validate an AI agent the way you’d validate a new sensor — check it against a known good value. That’s the right instinct, but it needs to be systematic, not a few spot checks during the demo.
Build a ground-truth test set before go-live: a few dozen real historical scenarios where you already know the correct answer, drawn from actual quality events, downtime incidents, and maintenance calls. Run the agent against each one and score it not just on “was it right” but on where it got its answer from — did it cite the current spec revision, or an outdated one sitting uncorrected in the document store? Did it pull from a UNS tag that’s actually mislabeled? Agents are very good at sounding certain even when the underlying retrieval was wrong, so surface the citation, not just the conclusion, every time.
Treat this as an ongoing validation loop, not a one-time gate. Documents change, specs revise, equipment gets modified — and if your context layer doesn’t have a process for keeping pace, the agent will confidently serve stale answers indefinitely. Assign document ownership the same way you’d assign tag ownership in the UNS: someone is accountable for knowing when a work instruction changes and pushing that update into the retrieval index, not just the file share.
The uncomfortable part
Building this context layer is a documentation and data-governance project wearing an AI costume. It requires the same unglamorous discipline as any master data cleanup: naming conventions, version control, ownership, and the political will to make operators and engineers actually write things down instead of keeping them in their heads. Plants that treat the AI copilot as a bolt-on to existing systems will get bolt-on results — fluent, confident, and occasionally dangerous answers. Plants that treat context engineering as the real project, with the agent as the visible output, are the ones who’ll get an assistant worth trusting on the floor.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
